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HOUSEKEEPING 


License: CC BY-SA 4.0 
Nice things: @FunnelFiasco 


Not-nice things: /dev/null 
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WHAT IS THIS TALK? 
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A LOOK AT FEDORA BUGS Fy 


From Fedora Linux 19 through Fedora Linux 32 
° Does not include Rawhide bugs 
Based on curiosity, not convincing 


° Asks more questions than it answers 





| started with Fl9 because that was the first 
release with an EOL closure type. It represents 
an obvious “modern era’ of our bugs. F32 is the 
last EOL release at the time of this 
presentation, so we stop there. 


| don't include Rawhide for two reasons. First, this 
talk is more focused on the user view of bugs 
and Rawhide Is (generally) not user-facing. Also, 
incorporating Rawhide bugs would require 
adding date-based searches and then 
Shoehorning them into the data set. That's 
more work than | wanted to put into it. 


THE BASICS 
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BUG REPORTS PER RELEASE 


Non-duplicate bugs by release 
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The obvious place to start is to just look at the 
number of (non-duplicate) bug reports per 
release. We can see a general downward trend 
In time, which may not be good news. Kar! 
Fogel says “an accessible bug database is one 
of the strongest signs that a project should be 
taken seriously —and the higher the number of 
bugs in the database, the better the project 
looks". 








BUGS PER COMPONENT: TOP 10 Fy 











selinux-policy 6477 
ecssciall 

anaconda aaa 
a a 

systemd 1488 
a 

nautilus ae 

Packagekit 1140 
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BUGS PER COMPONENT: BOTTOM 10 


© 12,082 (98.44%) components with < 100 bugs 
e 10,549 (85.95%) components with < 10 bugs 
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BUGS PER COMPONENT 


Bug counts per component 
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As we might expect, most components Nave very 
few bug reports. 


PRIORITY AND SEVERITY 
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Bugzilla says priority is the developer's rating of 
when it will be worked on and severity is the 
user's rating of impact. | am not convinced 
these are used in the way the documentation 
thinks they should be used. 








BUG PRIORITY 


Bug priority 


unspecified 


urgent 
high 


medium 
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| expected this to be all “urgent”. But it turns out 
since Bugzilla does not provide a default value, 
most people leave it unspecified. 


BUG PRIORITY (WHEN SPECIFIED) Fy 


Bug priority (unspecified excluded) 
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Removing the unspecified, we see a distribution 
that makes sense. Urgent bugs represent a 
small fraction. High is a larger segment, and 
medium is the highest. The reason | expect 
medium to be larger than low is that low- 
priority bugs probably go under-reported. 








BUG SEVERITY 


Bug severity 





unspecified 


Severity 


low 


medium 
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BUG SEVERITY (WHEN SPECIFIED) Fy 


Bug severity (unspecified excluded) 


medium 
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Removing the unspecified, we see a distribution 
that makes sense. Urgent bugs represent a 
small fraction. High is a larger segment, and 
medium is the highest. The reason | expect 
medium to be larger than low is that low- 
severity bugs probably go under-reported. 


DUPLICATE BUGS 
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DUPLICATE BUG REPORTS 


Duplicate bug reports 
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One thing | wanted to look at was the number of 
duplicate bug reports. This slide shows the 
duplicate and non-duplicate bug reports over 
time. Interestingly, even though the non- 
duplicate bug counts drop over time, the 
duplicate bug counts are relatively steady. 








% DUPLICATE BUG REPORTS 


Percent duplicate bugs 
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this is reflected clearly when looking at the 
percentage of duplicates by release. 








FEWEST DUPLICATES PER COMPONENT Fy 





ansible 0.77% 








btrfs-progs 1.22% 
a 
kubernetes 1.32% 
ae 
procps-ng 1.56% 
a ee 
snapd 1.60% 
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OOPS! ALL DUPLICATES! Fy 


e 643 components have a 100% duplicate count 
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| didn't look at all of these components, but | 
poked at a few. The duplicates were generally 
repeats of a Rawhide bug or a bug that was 
also filed against another component. 








MOST DUPLICATES PER COMPONENT Fy 





open-vm-tools 78.46% 








glib-networking 73.68% 

kf5-kglobalaccel 71.56% 
an oe 

gq 69.23% 

NearTree 66.67% 
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HOW TO GET MORE DUPLICATES? Fy 


Reports vs % duplicates 
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Intuitively, | expected the percentage of 
duplicates to be relatively steady as the bug 
count goes up. Above about a thousand bugs 
or so, that seems to be the case. The dropoff at 
the end is likely due to duplicates not being 
marked. 


ABRT REPORTS 
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Matthew Miller wondered how many bugs are 
from Numans versus automated reports. At a 
first pass, | used abrt (Specifically the presence 
of “[abrt]” in the summary field) as a proxy. 








PERCENT OF BUGS FROM ABRT Fy 


Percent abrt bugs 
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Fedora Linux 52 had a surprisingly low 
percentage of abrt bugs. 








BUG REPORT SOURCES 


Bug report sources 
mmm abrt 
ieee lm onon-abrt 
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BUG RESOLUTION 
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CATEGORIZING CLOSURES Fy 


e Happy resolutions: CURRENTRELEASE, ERRATA, 
NEXTRELEASE, RAWHIDE, UPSTREAM 


e Sad user resolutions: CANTFIX, DEFERRED, EOL, WONTFIX 


e Sad maintainer resolutions: INSUFFICIENT_DATA, 
NOTABUG, WORKSFORME 


e DUPLICATE is excluded here 
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We can argue about which closure types belong 
in which category, but this seems reasonable 
based on how I've seen them used. 








CLOSURES BY CATEGORY 


Fedora Linux bug resolutions 
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The happy closures tend to be smaller than I'd 
like. The sad user closures dominate the sad 
closures. 


EOL CLOSURE PERCENTAGE 


EOL close percentage 


% closed EOL 
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Every six months, we see complaints about how 
“Fedora never fixes my bugs, |'m done!” So | 
wanted to look at the closure percentage. Turns 
out it’s generally 40-50% of bugs that get 
closed EOL. What's interesting is the apparent 
periodicity to the chart. | don't have a good 
explanation for that. 








LOWEST EOL CLOSURES 





fedora-obsolete-packages 1.54% 








jackson-databind 2.04% 
python-bugzilla 2.94% 
rr ae 
nextcloud-client 3.00% 
a 
LibRaw 3.13% 
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ONLY EOL Fy 


°® 2,062 components have 100% (non-duplicate) EOL closure 
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HIGHEST NOT-100% EOL CLOSURES Fy 





tracker-miners 98.10% 








kactivitymanagerd 97.83% 
telepathy-idle 96.77% 
Cn ae 
dleyna-renderer 95.96% 
a 
supertux 95.65% 


@FunnelFiasco 


CC BY-SA 4.0 








TIME TO RESOLUTION (TTR) 
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Time to bug closure 


Frequency 





3000 4000 5000 
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How quickly are bugs resolved one way or 
another? 








TRR (LOG) 


Time to bug closure (log) 





5000 
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On a log scale, the graph looks pretty linear. 
That's neat. 








TTR BY RELEASE 


Boxplot grouped by Version 
TTR 
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Looking at TTR by release, it’s clear that there are 
a lot of high outliers. But we seem to be closing 
bugs faster over time. 








MEAN/MEDIAN TTR 


Bug time to resolution 
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Looking at the mean and median, this is clearly 
the case. 








10 LOWEST MEDIAN TTR BY COMPONENT Fy 











kipi-plugins 0.003 


darkice 0.004 





php-simplesamlphp-saml2_1 0.006 





gwe 0.008 


ipw2200-firmware 0.010 
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Some components are lightning fast. Probably 
because the bugs are opened by a maintainer 
who Immediately resolves it. 








10 HIGHEST MEDIAN TTR BY COMPONENT 





gtk-sharp2 3610.7 








a Ca 
mx 3610.7 

libdaemon 3107.9 

libgnomeui 2948.3 

libzdb 2724.7 
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Some components have a 10-year median 
closure time. That’s...a lot. 











REPORTS VS MEDIAN TTR 


Reports vs Median TTR 
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Does the TTR vary by the number of bug reports? 
Not really. 


HAPPY TTR 
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Let's do the same thing, but just for the happy 
closures. 








HAPPY TTR BY RELEASE 


Boxplot grouped by Version 
TTR 
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MEAN/MEDIAN HAPPY TTR BY RELEASE Fy 


Bug time to happy resolution 
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We're improving at fixing bugs! 








10 LOWEST MEDIAN HAPPY TTR 





golang-github-coreos- 0.003 
systemd 


spice-html5 0.005 








date 0.011 
akregator 0.014 
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10 HIGHEST MEDIAN HAPPY TTR 











gamin 3198.8 
eS ae 
nodejs-request 2718.8 
ce a ce 
poster 2684.5 
nodejs-jade 2410.1 
pisses | kao 
nodejs-qs 2233.9 
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You might have to wait years, but we can still get 
bugs fixed. 


SAD USER TTR 
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SAD USER TTR BY RELEASE 


Boxplot grouped by Version 
TTR 
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ME{AN,EDIAN} SAD USER TTR BY RELEASE Fy 


Bug time to sad user resolution 
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The large drop in sad user TTR from F19 to F20 is 
probably due to a large backlog of EOL 
closures. 








10 LOWEST SAD USER TTR 
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darkice 0.004 


apache-commons-compress 0.008 








polkit-qt 0.013 


xmlunit 0.017 


ssildump 0.023 
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10 HIGHEST SAD USER TTR 
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dmidecode 3610.7 
a ae 
esound 3610.7 
Sie ssa 
java_cup 3610.7 
as ae 
mx 3610.7 
res 
ytnef 3481.7 
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WHAT'S NEXT? 
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WHY DIDN'T YOU INCLUDE ___? Fy 


e Version changes 
e Assignees 


e Freeze process 
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Bugzilla queries don't report a count of version 
changes, but that would be very interesting to 
Know. 


| didn't include assignees because | didn't want a 
bunch of email addresses in the file. 


| could include a count of freeze process related 
bugs, | just didn't do that in this query. 








COMING SOON 


° Community Blog post(s) 
e Your theories 


e Probably more graphs! 
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EXPLORE IT YOURSELF Fy 


» httpos://oagure.io/fedora-pgm/fedora-bug-data 
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